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Abstract 

Existing refinement calculi provide frameworks for the stepwise development of imperative 
programs from specifications. This paper presents a refinement calculus for deriving logic 
programs. The calculus contains a wide-spectrum logic programming language, including 
executable constructs such as sequential conjunction, disjunction, and existential quan- 
tification, as well as specification constructs such as general predicates, assumptions and 
universal quantification. A declarative semantics is defined for this wide-spectrum lan- 
guage based on executions. Executions are partial functions from states to states, where 
a state is represented as a set of bindings. The semantics is used to define the meaning 
of programs and specifications, including parameters and recursion. To complete the cal- 
culus, a notion of correctness-preserving refinement over programs in the wide-spectrum 
language is defined and refinement laws for developing programs are introduced. The re- 
finement calculus is illustrated using example derivations and prototype tool support is 
discussed. 



1 Introduction 

Our goal is to provide a method for the systematic development of logic programs 
from specifications. We follow a refinement calculus approach (Back, 1980; Morgan 
& Robinson, 1987; Morris, 1987; Morgan, 1994), which provides a framework for the 
stepwise development of imperative programs from specifications. It makes use of a 
wide-spectrum language that includes both specification and programming language 
constructs. This allows a specification to be refined, step by step, to program code 
within a single language. The refinement steps are performed using refinement laws 
that have been proven correct within the framework. Once they are proven correct, 
they can be safely applied in any refinement, although in some cases their appli- 
cation involves proof obligations that must be discharged. The programs produced 
during the intermediate steps of the refinement process may contain specification 
constructs as components, and hence may not be code suitable for execution. The 
refinement is completed when the program contains only executable constructs. 

We define a refinement calculus for logic programming. The calculus contains 
a wide-spectrum logic programming language, including executable conjunction, 
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disjunction, and existential quantification, as well as specification constructs such 
as general predicates, assumptions and universal quantification, which are not in 
general executable. General predicates allow the effect of a program to be specified 
via properties expressed as logical formulae. Assumptions represent information 
about the context in which a program fragment will execute. An implementation is 
obliged to produce the specified result only if its assumptions arc satisfied by the 
context. The language also supports parametrised procedures and recursion. 

We define a declarative semantics for the wide-spectrum language in terms of 
executions, which are partial functions from initial to final states. A state in turn is 
represented as a set of bindings, where each binding is a mapping from variables to 
values. As is traditionally the case with logic programs, we consider only executions 
where the set of bindings in the final state are a subset of the bindings in the initial 
state. To complete the calculus, we define a notion of correctness-preserving refine- 
ment over programs in the wide-spectrum language and a set of refinement laws. 
The declarative nature of the semantics means that we do not distinguish a pro- 
gram that produces an answer once from a program that produces the same answer 
multiple times, nor do we consider the order in which answers are produced. Our 
semantics makes use of a least fixed point semantics that equates non-termination 
with the least defined program, abort. 

Section 2 of this paper presents related work. Section 3 summarizes the wide- 
spectrum logic programming language. Section 4 gives the basic definitions neces- 
sary for our formal semantics. Section 5 presents the semantics of the base language 
in terms of executions. Section 6 defines our notion of refinement. Section 7 gives 
the machinery for dealing with procedures and parameters. Section 8 discusses the 
semantics of recursion. Section 9 discusses refinement laws and presents a small 
example. Section 10 presents an extended example, which is the refinement of a 
program for the N-queens problem. Section 11 discusses Marvin, a prototype tool 
that supports the refinement calculus. 

Our semantics is described using the mathematical notation of the Z specification 
language (Spivey, 1992), except that we write sequences within square brackets to 
be consistent with logic programming notation. No familiarity with Z is assumed. A 
number of properties of the semantics are presented here without proof; the proofs 
of these properties are presented in (Hayes et al., 2000). 



2 Related work 

Traditionally, the refinement calculus has been used to develop imperative pro- 
grams from specifications (Back, 1980; Morgan & Robinson, 1987; Morris, 1987; 
Morgan, 1994). The increase in expressive power of logic programming languages, 
when compared with imperative languages, leads to a reduced conceptual gap be- 
tween a problem and its solution, which means that fewer development steps are 
required during refinement. An additional advantage of logic programming lan- 
guages over procedural languages is their simpler, cleaner semantics, which leads 
to simpler proofs of the refinement steps. Finally, the higher expressive level of 
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logic programming languages means that the individual refinement steps typically 
achieve more. 

There have been previous proposals for developing a refinement calculus for 
declarative languages. A refinement calculus for functional programming languages 
is discussed by Ward (1994). Kok (1990) has applied the refinement calculus to logic 
programming languages, but his approach is quite different to ours. Rather than 
defining a wide-spectrum logic programming language, Kok embeds logic programs 
into a more traditional refinement calculus framework and notation. 

There have been several proposals for the constructive development of logic pro- 
grams, for example in Jacquet (1993). Much of this work has focused on program 
transformations or equivalence transformations from a first-order logic specification 
(Clark, 1978; Hogger, 1981). Read and Kazmierczak (1991) propose a stepwise de- 
velopment of modular logic programs from first-order specifications, based on three 
refinement steps that are much coarser than the refinement steps proposed in this 
paper. This leaves most of the work to be done in discharging the proof obligations 
for the refinement steps, for which they provide little guidance. Another approach 
to constructing logic programs is through schemata (Marakakis, 1997). A logic pro- 
gram is designed through the application of common algorithmic structures. The 
designer chooses which program structure is most suitable to a task based on the 
data types in question. As such, the focus of this method is to aid the design of large 
programs. The refinement steps and corresponding verification proofs are therefore 
much larger. Deductive logic program synthesis (Deville & Lau, 1994) is probably 
the most similar to the refinement calculus approach. In deductive synthesis, a spec- 
ification is successively transformed using synthesis laws proven in an underlying 
framework (typically first-order logic). 

Two key aspects that make the refinement calculus approach different from these 
other proposals are the smaller refinement steps and the use of assumptions. Refine- 
ment steps are performed by applying individual refinement laws that have been 
proven correct within the framework; these laws have a much smaller granularity 
than the refinement steps in the other approaches. Applying these refinement laws 
may introduce proof obligations that must be discharged, however discharging these 
proof obligations is usually straightforward, and can often be handled automatically 
with suitable tool support. The use of assumptions allows refinements to be proved 
correct with respect to the context in which they appear. To our knowledge, such 
refinements in context are novel in the logic programming community. 

Deville (1990) introduces a systematic program development method for Pro- 
log that incorporates assumptions and types similar to ours. The main difference is 
that Deville's approach to program development is mostly informal, whereas our ap- 
proach is fully formal. A second distinction is that Deville's approach concentrates 
on the development of individual procedures. By using a wide-spectrum language, 
our approach blurs the distinction between a logic description and a logic program. 
For example, general predicates may appear anywhere within a program, and the 
refinement rules allow them to be transformed within that context. Similarly, pro- 
gramming language constructs may be used and transformed at any point. 

The motivation for the work by Hoare (2000) is to come up with unifying the- 
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(P) - 


specification 


{A} - 


assumption 


(Cl V 02) ■ 


disjunction 


(ci A c 2 ) - 


parallel conjunction 


(ci,c 2 ) ■ 


sequential conjunction 


(3 V • c) 


existential quantification 


(v v • c) 


universal quantification 


pc(t) - 


procedure call 



Fig. 1. Summary of wide-spectrum language commands. 

ories for programming, which is quite different from the motivation for our work. 
However, the logic programming constructs he considers and the semantics he uses 
are both very similar to the ones we use. 

3 Wide-Spectrum Language 

This section presents the wide-spectrum logic programming language (Hayes et al, 
1997), which combines both logic programming language and specification language 
constructs. It allows constructs that may not be executable, similar to Back's (1980) 
inclusion of specification constructs in Dijkstra's imperative language. This has the 
benefit of allowing gradual refinement without the need for notational changes 
during the refinement process. 

The constructs in the language are specifications (also called general predicates), 
assumptions, propositional operators, quantifiers, and procedure calls. A summary 
of the language is shown in Figure 1. 

Specifications: A specification (P), where P is a predicate, represents a set of 
instantiations of the free variables of the program that satisfy P. For example, the 
command (X = 5 V X = 6) represents the set of instantiations {5,6} for X, and 
the command (V = fact(U)) specifies the set of pairs of V and U such that V 
equals the factorial of U. The specification fail is defined by: 

fail == (false) 

(We use the notation '==' to indicate a definition.) The program fail always com- 
putes an empty answer set, like Prolog's fail. The null command, skip, is defined 

by 

skip == (true) 

Assumptions: An assumption {A}, where A is a predicate, expresses a require- 
ment on the context for a program fragment. For example, we may augment our 
specification of the factorial example by an assumption that U has been instan- 
tiated to be an element of the natural numbers before the factorial is evaluated: 
{ U € N}, ( V = fact(U)}. If assumptions about the context are formally expressed, 
implementations may take advantage of the assumptions, but need not establish (or 
indeed check) them. If these assumptions do not hold, the program fragment may 
abort. Aborting includes program behaviour such as nontermination and abnormal 
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termination due to exceptions like division by zero, as well as termination with 
arbitrary results. We define the (worst possible) program abort by 

abort == {false} 

Note that abort is quite different from the program fail, which never aborts, but 
has an empty solution set. 

Propositional Operators: There arc two forms of conjunction: a sequential 
form (ci,c 2 ) where command c\ is evaluated before c 2 ; and a parallel version 
(ci A c 2 ) where c\ and c 2 are evaluated independently and the intersection of 
their respective results is formed. The disjunction of two programs (ci V c 2 ) com- 
putes the union of the results of the two programs. We overload the symbols 'A' 
and 'V' as both operators on predicates and operators on commands. Because, for 
example, the meanings of (P A Q) and (P) A (Q) are identical, this does not usually 
cause confusion. 

The following three programs illustrate the behaviour of sequential and parallel 
conjunction, and show the difference between abortion and failure. 

PI == {X^0},(Y = 1/X) 
P2 == (X ^0),(Y = l/X) 
P3 == (I/0)A(F = 1/X) 

If each of the three programs is executed from a state where X = 0, PI will abort, 
while P2 will fail, producing an empty answer set. The behaviour of P3 is also 
equivalent to abort, because the predicate Y = 1/0 is not defined. 

Quantifiers: The existential quantifier (3 V • c) generalises disjunction, com- 
puting the union of the results of command c for all possible values of V. For 
example, the following may be part of the development of a factorial procedure: 

3 Ul, VI • ( Ul = U - 1 A VI = fact( Ul) A V = VI * U) 

Similarly, the universal quantifier (V V • c) computes the intersection of the results 
of command c for all possible values of V. 

Parametrised Commands and Procedures: We separate the definition of 
parametrised commands from procedures. A parametrised command has the form 

V :- c 

where V is a variable, and c is a wide-spectrum command. This notation is similar 
is the lambda calculus notation, (A V • c), and allows anonymous procedures to be 
used. 

A procedure definition has the form 

id = pc 

where id is an identifier representing the name of the procedure, and pc is a 
parametrised command as defined above. For example, 

id = V :- c 

defines a procedure called id with a formal parameter V and body c. A parametrised 
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command or a procedure identifier that is defined as a parametrised command may 
be applied to an actual parameter term. For example, a call on the procedure id is 
of the form id(t), where t is a term: the actual parameter. 

Our semantics only deals with procedures with a single parameter. However, no 
generality is lost because multiple parameters may be encoded using compound 
terms. For example, a procedure to calculate factorials may be specified by 

factorial = (U, V) :- { U e N}, { V = fact( U)) 

which is an abbreviation for the following definition with a single parameter W: 

factorial = W :- (3 U, V • ( W = ( U, V)),{U e N}, ( V = fact( U))) 

Commands: We define Cmd to be the set of commands in our language, built 
up from the constructs shown in Figure 1. 

4 Semantic Domains 

We begin our formal treatment of the semantics by defining the domains over which 
our semantics of programs are given. 

4- 1 Variables, values, and functors 

We have fixed domains of variables (Far), values (Val), and functors (Fun). El- 
ements of Var represent the variables that can occur in programs. This includes 
variables for which a program's answers give values, variables that are bound by 
universal and existential quantifiers, and variables used as formal parameters. Val- 
ues are the objects in the universe of discourse, denoted by ground terms. Functors 
represent the function symbols in our language that are used to construct com- 
pound terms. The arity of a functor is given by arity, which is a total function from 
functors to natural numbers (notationally, arity : Fun — ► N). Atoms are functors of 
arity zero. 

If we restrict our interpretation of ground terms to the Herbrand interpretation, 
as is typical in logic programming, Val is structured into atoms and compound 
terms. But we allow more structure than this; Val may be structured according to 
any algebra, taking into account whatever kind of term equality is appropriate for 
the application under consideration. For the purposes of this paper, all we assume 
is that there is a function apply, which models the application of a function to a 
sequence of values of length equal to the arity of the function, resulting in a value. 
We present the definition of apply as a Z axiomatic definition; the signature of apply 
is given above the line, and the definition in the form of a predicate is given below 
the line. In this case the signature states that apply is a (total) function that takes a 
functor, and returns a partial function (-h>) mapping sequences of values to values. 

apply : Fun — > (scq Val -+> Val) 

V/ : Fun • dom(apply /) C {s : seq Val \ ff=s = arity /} 
With this more general interpretation, given a functor / of arity n, 'apply /' may be 
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undefined for some sequences of values of length n. We write def E (or def P) for 
the predicate that is true precisely when the expression E (or predicate P) is well- 
defined: that is, when all function applications occurring within it are well-defined. 
For the Herbrand interpretation, or indeed for any other interpretation in which all 
functions are total, def E = def P = true for all expressions E and predicates P. 



4-2 Bindings, States and Predicates 

A binding is a total function, mapping every variable to a value. 

End == Var — > Vol 

Each binding corresponds to a single ground answer to a Prolog-like query. The 
mechanism for representing "unbound" variables is described below. 
A state is a set of bindings. 

State == P End 

A state corresponds to our usual notion of a predicate with some free variables, 
which is true or false once provided with a binding for those variables, i.e., for a 
binding in the state. Given a predicate P, we write P to denote the set of bindings 
satisfying P. For example: 

false = 

true = End 

T^3 = {b : End \ b X = 3} 

X < Y = {b: Bnd\b X < b Y} 

A completely unbound variable is represented by a possibly infinite state that has 
one binding to each element of Vol. For example, if we suppose that Var contains 
just the variables {X , Y, Z}, Vol is the set {0, 1}, and / has arity one and is total, 
the set of solutions to the equation Y = f(X) is represented by the following set of 
bindings. 

{{X 1 ► , Y 1 ► apply / [0], Z ^ 0}, 
{X^O, reapply / [OUhI}, 
{X~l, reapply / [1],Zh0}, 
{X^l, F^apply / [l],Zh-l}} 

The expression X x constructs a pair of its operands; it is equivalent to (X, x). 

We do not concern ourselves in this semantics with finite or infinite representation 
of infinite states. Our model allows a successful execution that terminates in an 
infinite state. Some infinite states may correspond to Prolog answer sets that can 
be finitely enumerated, and others may not. 
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4.3 Terms 

A Term is a variable, or a functor with a (possibly empty) finite sequence of terms 
(the arguments). We model a term via the following data type constructor. 

Term ::= varT{{Var}} \ funT((Fun x seq Term)) 

For any variable V, varT(V) is a term, and if / is a functor and ts is a sequence 
of terms, then funT(f, ts) is a term. 

A term may have a value when evaluated relative to some binding, or it may be 
undefined if the term involves the incorrect application of a function. We define a 
partial function eval that evaluates a term relative to a binding. 

eval : Term — » (Bnd -+> Val) 

eva\(varT( V)) = {\b : Bnd • b V) 
eva\(funT(f , ts)) — {b : Bnd; vs : seq Val \ 

(V t : rants • b G dom(eval t)) A 

vs = map(\ t : Term • eval t b)(ts) A 

vs G dom(apply /) 

• h 1 ► apply / vs} 

The notation {x : T \ P • E} describes the set of values of the expression E, 
for each x of type T for which P holds (when P is true we may omit it, i.e., 
{x : T • E}). Thus, {x : T | P • x E} is the function (set of pairs) whose 
domain is the set of x : T satisfying predicate P, and which maps each such x 
to the corresponding value of expression E. In the definition of eval, to evaluate 
a compound term funT(f , ts) with respect to a binding 6, all of the terms in the 
sequence ts must be able to be evaluated with respect to b, the resultant sequence 
of values vs is defined by mapping a function that evaluates a single term with 
respect to b over the sequence ts, and vs must be in the domain of apply /. 

For a term t, defined t is the set of states for which t is defined for every binding 
in the state. 

defined : Term — > P State 

defined t = {s : State \ s C dom(eval t)} 

For a variable V, term t, and state s, assign V t s is the same as state s, except 
that in each binding within s the value of V is replaced by the value of t in that 
binding. 

assign : Var — > Term — > State State 

assign V t = (A s : defined t • {b : s • b © {V i-> eval t b}}) 

In the definition, f(Bg stands for function / overridden by function g. The expression 
/ g is the same as function /, but with everything in the domain of g mapped to 
the same objects that g maps them to (outside of the domain of g, f © g behaves 
like/). 

For some term t, free t is the set of free variables in t: 
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free : Term — ► P Var 

free(varT(V)) = { V} 

hee(funT(f , ts)) = [j{t : ran ts • free t} 

Similarly, for a command c, free c defines the set of free variables in c. Since we do 
not formally define the predicates allowed in specifications and assumptions here, 
we do not define free c formally. 



We define the semantics of our language in terms of executions, which are mappings 
from initial states to final states. The mapping is partial because the program is 
only well-defined for those initial states that guarantee satisfaction of all the pro- 
gram's assumptions. Executions satisfy three healthiness properties below. These 
properties restrict executions to model pure logic programs. 

1. If a command is guaranteed to terminate from an initial state P whose bind- 
ings all satisfy some predicate P, it must also guarantee to terminate from all 
those initial states P', where P' =>■ P. We thus require that any subset s' of 
a set s that is in the domain of an execution e, is also in the domain of e. 

V s : dom e • (V s' : P s • s' G dom e) 

In addition, if a command is guaranteed to terminate from initial state P and 
it is also guaranteed to terminate from initial state Q, it must terminate from 
an initial state P V Q. Thus, if all sets in a set of states ss are in the domain 
of e, then their union is also in the domain of e. 

V ss : P(dom e) • IJss G dom e 

As we show in (Hayes et al., 2000), these together are equivalent to the fact 
that the domain of e is the powerset of the set of all bindings, b, such that 
the singleton set {b} is in the domain of e. 

dom e = P{b : End \ {b} G dom e} 

2. Because of the constraining nature of logic programs (command execution 
cannot decrease "groundedness" ) for any state s in the domain of an execution 
e, the set of bindings in the output state e(s) must be a subset of s. 

V s : dom e • e(s) C s 

Consider a state with variables X and Y which can take values in the set 
{0, 1} and the execution e that represents the program (X = Y). Intuitively 
the set of initial states for a specification (P) consists of those states for which 
P is defined. In this example the domain of e consists of all subsets of 
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S = {{IhOJh 



0},{X^0, Y ~1}, 
0},{X^1, Y ^1}} 
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Given an initial state, the effect of executing (X = Y) is to filter out those 
bindings b for which X = Y is not true. In particular e(S) = {{X 0, Y ^ 
0},{X Hl,yHl}}C S. 
3. For a set of bindings s, the output set of bindings consists of all those bindings 
b, such that the singleton set {b} is preserved by e. 

Vs : dome . e(s) = {b : s | e({b}) = {b}} 

For each of the singleton states in the example state S above, 

e({{X i ► 0, Y i ► 0}}) ={{IhOJh 0}} 
e({{X~0,Y~l}}) = {} 
e({{X~l,Y^0}}) = {} 
e({{X h1,7h 1}}) = {{X h1,7h 1}} 

Thus e(S) consists of the bindings which are individually preserved by e. 
We thus define: 

Exec == {e : State -+> State \ 

dome=P{6: End \ {b} G dom e} A (1) 
(Vs : dome • e(s) Cs)A (2) 
(Vs : dome . e(s) = {& : s | e({&}) = {fo}})} (3) 

Note that Property (1) implies that 6 dom e for all executions e. Also, from 
Property (2), e({b}) is either {&} or 0. In (Hayes et al, 2000), Property (3) is 
shown to be equivalent to cither of the following two properties. 

Vs : dome • e(s) ={J{b : s • e({b})} (4) 
Vs : dome •Vs' : Ps • e(s') = e(s) n s' (5) 

Property (4) shows that an execution e can be determined by considering the effect 
of the execution on each singleton binding, and then forming the union of the 
results. Property (5) shows that the result of executing a command in a subset s' 
of some state s is consistent with executing the command in state s and restricting 
the results to those in s'. This property is similar to the property quoted by Hoare 
(2000) and attributed to He Jifeng, as one that characterises a pure logic program. 
For example, Prolog's var does not satisfy the property. 



5.2 Semantic function for commands 

We define the semantics of the commands in our language via a function that takes 
a command and returns the corresponding execution. 

exec : Cmd — > Exec 

The semantics of the basic commands (excluding procedure calls, which are treated 
in Section 7.5) is shown in Figure 2. In the remainder of this section, we explain the 
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exec({P)) = (A s : V(def P) • s n P) 
exec({A}) = (A s : P(def iA/l) • s) 
exec(fail) = exec({false)) = (As : 5iafe • 0) 
exec(abort) = exec({/a/se}) = {0 0} 
exec(skip) = exec({true)) = (As : S'iaie • s) 
exec(ci V C2) = exec ci U exec C2 
exec(ci A C2) = exec ci Pi exec C2 
exec(ci , C2) = exec ci g exec C2 
exec(3 V • c) = exists V(exec c) 
exec(V V • c) = forall l/(exec c) 

Fig. 2. Execution semantics of basic commands 

definitions. In (Hayes et al, 2000), we show that all executions constructed using 
the definitions satisfy the healthiness properties of executions. 

In Section 7, where we discuss procedures and parameters, we extend the defini- 
tion of exec with an environment, which maps procedure identifiers to their corre- 
sponding (parametrised) executions. For simplicity, we first present the semantics 
of the basic commands ignoring the environment. 

5.3 Specifications and assumptions 

A specification (P) is defined for all states s such that P is defined for all bindings 
in s; the result of executing specification (P) consists of those bindings in s that 
satisfy P. 

An assumption {,4} is defined for all states s such that A is defined and A holds 
for all bindings in s; the result of executing assumption {A} has no effect (the set 
of bindings remains unchanged) . 

The definition for the special-case specification fail is the constant function that 
returns the empty state, no matter what the initial state is. Hence for any command 
c, including abort, 

fail , c = fail 

because fail maps any state to the empty state. 

The definition for the special-case assumption abort is the function mapping the 
empty state to the empty state. Hence for any command c, 

abort , c = abort 

because the domain of abort contains only the empty state, which it maps to the 
empty state. Note that the empty state is preserved by any command, i.e., for any 
command c, (exec c)(0) = 0. 

The definition of the special-case specification skip is the identity function on 
states. Hence for any command c, 

c , skip = c = skip , c. 
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5-4 Pr oppositional operators 

Disjunction and parallel conjunction are defined as pointwise union and intersection 
of the corresponding executions. 

_ R _ : Exec x Exec — » Exec 
_ U _ : Exec x Exec — > Exec 

(ei R e 2 ) = (A s : dom ei R dom e 2 • (ei s) R (e 2 s)) 
(ei U e 2 ) = (A s : dom ei R dom e 2 • (ei s) U (e 2 s)) 

For a conjunction (ci A c 2 ), if a state s is mapped to s' by exec c\ and s is mapped 
to s" by execc 2 , then exec(ci A c 2 ) maps s to s 1 R s". Disjunction is similar, but 
gives the union of the resulting states instead of intersection. The command abort 
is a zero of both disjunction and parallel conjunction, skip is the unit of parallel 
conjunction, and fail is the unit of disjunction. 

Sequential conjunction (ci , c 2 ) is defined as function composition of the corre- 
sponding executions. The domain of the function (Xx : T \ P • E) is those values 
of x in T for which P holds, and the range is the corresponding set of values for E. 

_ 1, _ : Exec x Exec — ► Exec 

(ei 8 e 2 ) = (As : dom ei | ei(s) G dom e 2 • e 2 (ei(s))) 

If exec ci maps state ,s to s' and exec c 2 maps s' to s" , then exec(ci , c 2 ) maps 
s to s". If either s is not in the domain of exec ci or s' is not in the domain of 
exec c 2 , then s is not in the domain of exec(ci , c 2 ). The command skip is the unit 
of sequential conjunction, and both abort and fail are left zeroes. 

5. 5 Quantifiers 

For a variable V and a state s, we define the state 'unbind V s' as one whose bindings 
match those of s in every place except V, which is completely unconstrained. 

unbind : Var — > State — ► S'taie 

unbind V s = {fe : s; 1 : VaZ • 6 {V i-> a;}} 

Execution of an existentially quantified command (3 V • c) from an initial state s 
is defined if executing c is defined in the state s' , which is the same as s except that 
V is unbound. The resultant state after executing c consists of all those bindings b 
in s such that there is a value, x, for V such that execution of c retains the binding 
b © {V 1 — ► a;}. We thus make the following definition of the existential quantifier 
for executions. 

exists : Var — ► Exec — > .Rcec 

exists V e = (A s : S'tate | unbind V s e dom e 

• {6 : s I (3 2; : Val • e({b © { V ^ x}}) ^ 0)}) 

Universal quantification behaves in a similar fashion, except that for (forall V e) to 
retain a binding b, execution of e must retain b © { V ^ x} for all values x. 
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forall : Var — ► Exec — > iJxec 

forall V e = (As : .State | unbind 7s£ dome 

• {b:s | (Var: Vaf • e({b { V ^ x}}) ^ 0)}) 

6 Refinement 

An execution e\ is refined by an execution e 2 if and only if e 2 is defined wherever 
e\ is and they agree on their outputs whenever both are defined. This is the usual 
"defincdness" order on partial functions, as used, for example, by Manna (Manna, 
1974): it is simply defined by the subset relation of functions viewed as sets of pairs. 
We define refinement, C, as a relation (<->) between Execs. 

_ C _ : Exec <-> i&rec 

ei C e 2 O ei C e 2 

For the commands Cmd in our language, we define refinement in terms of refine- 
ment of the corresponding executions. 

_ C _ : Cmd <-> Cmd 

ci C C2 <=> exec ci C exec c 2 

Finally, refinement equivalence (□) is defined for Cmd and Exec as refinement 
in both directions. 

_ O _ : Cmd Cmd 

_ O _ : i3rec <-> i?xec 

ci □ c 2 <^ c\ C c 2 A c 2 C ci 
d O e 2 <^> ei C e 2 A e 2 C ei 

Refinement is a preorder — a reflexive and transitive relation — because subset is 
a preorder on sets. 

6.1 Lattice properties 

The refinement relation forms a meet semi-lattice over Exec. 

• 'C' is a partial order because 'C' is a partial order on sets; 

• meets exist: e\ n e 2 = ei n e 2 ; 

• there is a unique bottom element, corresponding to the command abort (re- 
call that exec abort = {0 0}). 

Note that joins do not exist in general, because e\ U e 2 may not be a function; 
and there is no top element. For ei U e 2 to be defined, we require that ei U e 2 is 
a function and not simply a relation (i.e., e\ returns the same state as e 2 for the 
states where both arc defined) . Even under that condition, the result is not simply 
ei U e 2 , because that would violate condition (1) of executions. Instead, we define 



14 



I. Hayes et al. 



e\ U e 2 by adding to ei U e 2 mappings for all states that consist of bindings for which 
either e\ or e 2 is defined. 

_ n _ : Exec x Exec — > Exec 
_ U _ : Exec x Exec Exec 

ei l~l e 2 = ei n e 2 

(ei, e 2 ) e dom(_ U _) 4=> (Vs : dom ei PI dom e 2 • ei(s) = e 2 (s)) 
(ei, e 2 ) e dom(_U_) 

eiUe 2 = (As: P(U(domei Udome 2 )) • {b : s | (d U e 2 )({&}) 7^ 0}) 

In (Hayes ef aL, 2000), we show that l~l and U (when the latter is well-defined) 
preserve the healthiness properties for executions. 

If e\ C e 2 then their join e\ U e 2 is defined (and is e 2 ). As a result, we can define 
joins for chains. We first define a chain of executions: 

Chain == {ec : N -> Eiec | (V i : N • ec(i) C ec(i + 1))} 

Note that we define every chain as an infinite sequence; a finite chain is simply 
modelled as an infinite chain in which the last clement is repeated infinitely often. 
If ec is a chain, then ec(i) U ec(i + 1) exists for all i and is equal to ec(i + 1). We 
therefore define the join of a chain as follows. 

jj : Chain — > Exec 

[J ec = (J(ran ec) 

7 Procedures and parameters 

To simplify the semantics, we treat procedures, parameters and recursion as sepa- 
rate, though related, concerns in a manner similar to Morgan (1988). 

7.1 Parametrised commands 

To deal with parameters, we introduce the notion of a parametrised command. Given 
a variable V and a command c, the expression V :- c denotes the parametrised 
command (PCmd) that, when provided a term argument t, behaves like c[i/V], 
i.e., the command c with every occurrence of V replaced by t. In order for V :- 
c to be well-formed, we require that c has no free variables other than V, i.e., 
free(c) C {V"}; any other variables in c must be explicitly quantified. 

The semantics of parametrised commands is given by parametrised executions, 
which arc functions mapping actual parameter terms to executions. 

PExec == Term — ► Exec 

7.2 Environments 

To handle procedure definitions and recursion, we introduce a given set of procedure 
identifiers (PIdent) and an environment, which maps procedure identifiers to their 
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corresponding procedure executions. 

Env == PI dent PExec 
Hence we change the definition of exec to add an environment parameter. 

i exec : Env — > Cmd — > Eiec 

The definitions we have given in Section 5 do not depend directly on the environ- 
ment. The only change required is to add the environment parameter to the calls 
on exec for subcomponents, e.g., for an environment p: 

exec(p)(ci A C2) — (exec p c 2 ) R (exec p c 2 ) 

7.3 Parametrised executions 

For an actual parameter term t, the execution of a parametrised command V :- c 
is a function that is defined for all states s for which evaluation of t is defined for 
all bindings in s, and for which c is defined when V is bound to the value of t for 
each binding in s. We determine the result of executing the parametrised command 
by determining its result for each binding b in s. A binding b from a state s will 
be retained by the execution of the parametrised command applied to term t if the 
execution of c from a state consisting of {&}, but with the formal parameter V 
replaced with the value of term t in binding b, retains that binding. Recall that the 
result of executing a command on a singleton set is either that singleton set or the 
empty set. 

pexec : Env — > PCmd — > PExec 

pexec(p)( V :- c) = (Xt : Term • 

(As : defined t | assign V t s e dom(exec p c) • 
{& : s I (exec p c)(assign V f {&}) ^ 0})) 

This definition only applies to non-recursive parameterised commands. The defini- 
tion of pexec for recursion is presented in Section 8. 

7.4 Refinement 

We define refinement between parametrised executions p\ and p 2 by requiring re- 
finement for every possible value of the parameter. We also define refinement equiv- 
alence between parametrised executions in the obvious way. 

_ C _ : PExec «-> PExec 
_ O _ : PExec <-> PExec 

(Pi E P2) (V t : Term • ( Pl t) C (p 2 t)) 
(pi □ p 2 ) (Vf : Term • (pi f) □ (p 2 t)) 

Refinement between parametrised commands pci and pc 2 is defined, as expected, 
in terms of refinement between the corresponding parametrised executions. Because 
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the meaning of a parametrised command depends on the environment, this becomes 
a parameter to the refinement relation; this parameter is written as a subscript p. 

_ C p _ : Env -> (PCmd PCmd) 
_ Q p _ : few -> (PCmd <-> PCW) 

(pci C p pc 2 ) 4=> (pexec p pc\ C pexec p PC2) 
(pci Q p PC2) (pexec p pci O pexec p PC2) 

When the environment p is clear from the context it may be elided. 

7.5 Procedure call 

A parametrised command may be directly applied to a term; the result is a com- 
mand, the semantics of which is defined as follows. 

exec p ((v :- c)(f)) = pexec p (v :- c) i 

The syntax of a procedure call is id(t), where t is a term and id is a procedure 
identifier. The parametrised command which is the definition of id in the environ- 
ment is applied to t. If id is not defined in the environment, the result of a call on 
id is abort. 

exec p id(t) = if id 6 domp then (p id t) else (exec p abort) 

7.6 Lattice properties 

The lattice properties of Exec can be lifted to PExec. 

_ Fl _ : PExec x PExec — > PExec 
_ LJ _ : PExec x PExec PExec 

Pi H P2 = (A i : Term • pi irip 2 

(pi,P2) G dom(_LJ_) (Vf : Term • (pi £,p 2 £) € dom(_U_)) 
(pi , P2) S dom(_ LJ _) => pi LJ p 2 = (A < : Term • pi £ U p 2 i) 

PCftam == {p : N -> Pfeec (V i : N • C p(i + 1))} 

[J : PCAain -> PErec 

[J p = (A i : Term • |J(A i : N • p i f)) 

8 Recursion 

If id is an identifier and pc is a parametrised command, possibly containing in- 
stances of id, the recursion block re id • peer is also a parametrised command. 
Intuitively, a call on the parametric recursion block re id • V :- . . . id(t) . . . er is 
similar to a call on the Prolog procedure defined by id(V) : - ... id(t) .... 
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8. 1 Semantics of recursion blocks 

A recursion block embeds one or more recursive calls on the block inside a context. 
Thus, a context is a function from one parametrised command (the recursive call) 
to another (the entire body of the recursion block): 

Ctx == PExec -> PExec 

Intuitively, to represent re id • V :- . . . id(t) . . . er, we define the context C such 
that C(p) = V :- . . . p(t) .... In this example, C embeds a call on p in the context 
given by id, and also provides p with the parameter t. Formally, we define a function 
that extracts a context from a recursion block. 

context : Env — > PCmd -+> Ctx 

context(p)(re id • peer) = (Ap : PExec • pexec(p © {id i— > p})(pc)) 

This function is partial because it is only defined for PCmds that are recursion 
blocks. 

To define the semantics of recursion blocks we use a fixed point construction, 
which is defined for all monotonic contexts — see Knaster-Tarski Theorem (Nelson, 
1989). We first define the set of monotonic contexts. 

MCtx == {C : Ctx | (Vp,p' : PExec • (p C p') => (C(p) C C(p')))} 

This monotonicity property holds for every context C that can be constructed in 
our language (Hayes et al, 2000). 

Now the meaning of a recursion block is the least fixed point of the context C 
provided by the recursion block (written fix C), where: 

fix : MCtx -> PExec 

(VC : MCtx • fix C = C(fix C)) 

(VC : MCte; p : Pfeec • (C(p) = p) (fix C C p)) 

Hence the meaning of a recursion block is the least fixed point of the context 
corresponding to the recursion block. 

pexec(p)(re id • peer) = fix(context(p)(re id • peer)) 

8.2 Constructing the fixed point 

To simplify this and the next section, we use the syntax of parametrised commands 
to stand for their PExecs and we assume a fixed environment p, which is augmented 
with a single recursive definition. 

The least defined command is abort. The least defined parametrised command 
is a parametrised command with abort as its body: 

aborti == V :- abort 

For a recursion based on a monotonic context C, we construct the chain of programs: 
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pc : PChain 

pc = (Xi : N • C'(aborti)) 

That is, we have 

pc(0) = C° (aborti) = aborti 

pc(i + 1) = C J+1 (aborti) = C{pc(i)) 

The sequence pc forms a chain ordered by C and has a join (Ujjc). By the Limit 
Theorem (Nelson, 1989), [Jpc = fix C, as long as C is a chain-continuous function. 
For a chain pc for which the join [Jpc exists, a function C is chain- continuous 
provided C([Jj>c) = |_J(A i : N • C(pc(i))). All the contexts C that can be constructed 
in our language are chain-continuous (Hayes et al., 2000). 

For example, the following equivalences hold in our semantics. 

rep • X :- p(X) er □ aborti 

rep • X :- (X = 1} ,p(X)er □ X :- (X = 1) , abort 

rep • X :- {X = 1) A p(X)er □ aborti 

rep • X :- {X = 1) V p(X)er □ aborti 

The first is the trival non-terminating recursion. The second fails if X is bound to a 
value other than one, otherwise it is a non-terminating recursion. The last two both 
use parallel operators that evaluate both arguments; hence they both degenerate 
to a non-terminating recursion. 

8.3 Mutual recursion 

In this paper we do not explicitly handle the definition of a set of mutually recursive 
procedures. Such a set can always be encoded as a single procedure and hence given 
a semantics via this encoding. For example, a set of mutually recursive procedures 

Pi = Vi :- G x 

Pn = V n :- C n 

may be encoded as a single procedure 

p = (I, V u . . . , V n ) :- {I = 1), Ci V . . . V (I = n), C n 

where the parameter / (a fresh name) encodes which of the original procedures is 
being called and the parameter names Vi, . . . , V n are assumed to be distinct. A 
call of the form pi(t) is then encoded as p(l, . . . ,_). 

9 Refinement laws 

This section presents a number of refinement laws for the step-wise refinement of 
logic programs. Each of these laws has been proven with respect to the semantics, 
using the execution properties listed in Section 5.1. Appendix A presents a summary 
of refinement laws used in this paper. 
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9.1 Algebraic laws 

The commands in the wide-spectrum language obey a number of algebraic proper- 
ties. Parallel conjunction and disjunction are commutative, but sequential conjunc- 
tion is not. Parallel conjunction and disjunction as well as sequential conjunction 
are associative. Parallel conjunction can be refined to sequential conjunction using 
the rule pand-to-sand because in the sequential form c 2 can assume the context 
established by c\, but in the parallel form it cannot: 

ci A c 2 E ci , c 2 

To prove such a law we show 

exec(p)(ci A c 2 ) C exec(p)(ci , c 2 ) 
= exec p ci R exec p c 2 C exec p ci § exec p c 2 

which can be shown via the definitions of R and g, and the properties of executions. 

Parallel conjunction and disjunction distribute over each other. Sequential con- 
junction distributes over parallel conjunction and disjunction in the following ways: 

ci , (c 2 A c 3 ) □ (ci , c 2 ) A (ci , c 3 ) 

ci , (c 2 V c 3 ) □ (ci , c 2 ) V (ci , c 3 ) 

ci A (c 2 , c 3 ) C (ci A c 2 ) , c 3 

(ci V c 2 ) , c 3 □ (ci , c 3 ) V (c 2 , c 3 ) 

The existential and universal quantifiers distribute over disjunction and (parallel) 
conjunction respectively. 

(3 V • ci V c 2 ) □ ci) V (3 F • c 2 ) 

(V V • ci A c 2 ) □ (V V • ci) A (V V • c 2 ) 



9.^ Monotonicity laws 

Each of the language constructs is monotonic with respect to the refinement rela- 
tion. Monotonicity guarantees that the result of replacing a component of a program 
by its refinement is itself a refinement of the original program. 

For parallel and sequential conjunction, and disjunction, there are laws stating 
that the command can be refined by refining either of the arguments of the top-level 
operator; e.g., the rule por-mono: 

ci E c 2 ; c 3 C c 4 
ci V c 3 C c 2 V C4 

For the existential and universal quantifiers we give monotonicity laws stating 
that the command can be refined by refining the quantified sub-command; e.g., the 
rule exists-mono for existential quantifiers: 

ci C c 2 



3V»c 1 ^3V»c 2 
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9.3 Predicate lifting 

The predicate lifting laws state that predicate operators inside of specifications can 
be lifted to their corresponding command operator. For example, the rule lift-pand 
states that predicate conjunction within a specification can be lifted to parallel 
conjunction at the command level: 

(PA Q) □ (P)A(Q) 

Similar rules are given that lift predicate disjunction to command disjunction, and 
predicate quantifiers within specifications to the corresponding command quanti- 
fiers. 



9-4 Specification and assumption laws 

Programs can be refined by weakening, removing and introducing assumptions. 
For example, the law weaken-assumpt states that an assumption can be refined by 
weakening the predicate: 

A ee> B 
{A} E {B} 

where for predicates A and B, A entails B (A ^ B) iff for all bindings b, A is true 
at b implies B is true at b, i.e., A ^ B 44> A C B. 

A program can be refined by replacing a specification by an equivalent one; the 
law equivalent-spec states that if P and Q are equivalent, then the program (P) is 
equivalent to the program (Q); i.e., 

P=Q 

(P) □ (Q) 

where predicates P and Q are said to be equivalent (P = Q) iff for all bindings b, 
P is true at b iff Q is true at b, i.e., P = Q ^=> P = Q. 

9. 5 Context 

We have already seen that commands arc refined in the context of a program 
environment p. A second kind of context is an "assumption" context (based on the 
precondition context used in the program window inference presented in (Nickson 
& Hayes, 1997)). For example, consider the command '{v4},S"; in refining S and its 
subcommands, we may assume that the predicate A holds. Rather than propagating 
the assumption throughout S and its subcommands, we add the assumption A to 
the context of the refinement. 

To allow refinement in the context of assumptions, we need to introduce the 
notion of pointwise refinement, E, defined as: 
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_ U- p _, _ Q _ : Env — > Cmd x Cmd — > (Bnd — > boolean) 

c i c 2 = (A & : -Snd • {&} G domexec p Ci => 

({&} 6 domexec p c 2 A exec p ci {6} = exec p c 2 {&}) 

C2 c 2 = ci E p c 2 A c 2 E p ci 

As with command refinement we shall omit the environment when it is clear from 
the context. Note that when there are no assumptions (or equivalcntly the assump- 
tion is true), pointwise refinement is equivalent to command refinement, i.e., 

ci C c 2 (true e$> (ci E c 2 )) 

The laws weaken-assumpt and equivalent-spec can be restated to include the current 
context, T. 

T^(A=>B) T^(P^Q) 
T^({A}K{B}) r^((P)Q(Q)) 

When refining c\ in the context {^4} , c\ we may assume A holds by extending 
the current context; this is encapsulated in the rule assumpt-in-context: 

r A A ee> (ci E c 2 ) 

r ^ {A} , ci e {^} , C2 

Similarly for specifications we have the rule spec-in-context: 

r A P e> (ci e ca) 

r ^ (P) , ci e (p) , C2 

If a command c\ refines to c 2 in a context T, then it refines to c 2 in any stronger 
context. In particular, given a refinement law of the form c\ E c 2 , then c\ E c 2 in 
any context, i.e., 

ci E c 2 
r ^ (ci E ca) 

This means that any of the (command) refinement laws that do not have proof 
obligations, such as the algebraic and predicate laws given earlier, can be applied 
in any context. We also observe that each of our language constructs are monotonic 
with respect to the pointwise refinement relation in any context. For example, for 
disjunction the following law holds. 

1^ ( Cl Ee 2 ); (c 3 Ee 4 ) 

r ee> (ci V c 3 E c 2 V C 4 ) 

Notice this law is more general than por-mono, which is an instance of the above 
law with the assumption context being true. 
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9.6 Recursion introduction law 

We desire a refinement law that allows us to refine a non-recursive parameterised 
command into a recursive block. That is, for pc a parameterised command and 
C(id) a command that may depend on the (fresh) procedure identifier id and the 
variable V, we want to derive a law with the following as the conclusion. 

pc E p re id • V :- C(id) er 

We will derive such a law using well-founded induction, the general form of which 
is, for some predicate and well-founded relation -<, 

(V Y • Y -< V => <j>(Y)) ^ cf)(V) 

VI • (j)(X) 

We take <f>(X) to be pc(X) E p (reid • V :- C(id)er)(X). Given this, and the 
definition of refinement for parameterised commands, the predicate VI • <fi(X) on 
the bottom line is equivalent to our initially stated refinement, 

pc CI p reid • V :- C(id) er 

Now we instantiate the top line of the well-founded induction law using the same (j>. 

(V Y : Term • Y -< V => pc{ Y) E p {reid • V :- C(id) er)(F)) ee> 
pc( V) E p (re id • V :- C(id) er)( V) 

As id was a fresh name, we define p' — p U {irf re id • V :- C(zd) er}. The top 
line can now be written as 

(V Y : Term • Y ~< V => pc(T) E p , id(K)) 
pc( V) E p , (re id • V :- C(id) er)( V) 

Now we simplify the expression on the right-hand side of the entailment so as to 
make the whole expression useful as a proof obligation for the recursion introduction 
law. 

pc{V)\Z p , (reid* V :-C{id)er){V) 
= unfold 

pc{ V) E p , ( V :- C(re id • V :- C(id) er))( V) 
= parameter application; definition of id in p' 
P c(V) £ p ,C(id) 

Noting that A => c E p c' = {A}, c E p c', the process produces the following 
recursion introduction law, recursion-intro. 

(V Y : Term • { Y -< V} , pc( Y) E p , id( Y)) pc( V) C(id) 



pc C p reid • V :- C(id) er 
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9. 7 Example 

We derive a recursive implementation of a factorial function from the definition of 
factorial, which is: 

fact(O) = 1 

fact(n + 1) = fact(n) x (n + 1), for n > 

Starting with an initial abstract specification S, we wish to refine this to a con- 
crete program C, such that C can easily be translated (automatically) into an 
executable program. We adopt a step-wise refinement approach, where we intro- 
duce a number of intermediate programs Ij (where 1 < j < n for some natural n), 
representing refinements of the previous program, i.e., S E h E ■ • • E I n E C This 
is achieved by making use of the transitive nature of the refinement relations. 

Monotonicity rules are used to transform a subcommand of the program. The sub- 
command to be refined is indicated by the markers l and j. For binary commands 
we use the more specific monotonicity rules used to focus on the left or right-hand 
side of a command. Often a single step in the example actually corresponds to the 
application of multiple nested monotonicity rules. 

Our factorial program has parameters U and V. It can assume U <E N and must 
establish V — fact(U). 

(U, V) :-{UeN},(V=fact(U)) 

We make use of recursion-intro, which allows one to assume 

V 171, VI • { Ul -< U}, { Ul G N}, ( VI = fact( Ul)) E p , /( [71, VI) 

where / is a fresh procedure identifier and p' = p U {/ i— > re/ • ( U, V) :- C(f) er} 
and refine 

{U GN},(V=fact(U)) 

in this context. Focusing on the specification ( V — fact( U)) 7 we can assume the as- 
sumptions prior to the specification; in order that this assumption (and assumptions 
introduced to the context later) can be used we now use the pointwise refinement 
relation with the extended environment p 1 . 

Assumption 1: 

V 171, VI • { UK U} , { Ul e N} , ( VI = fact( Ul)) /( Ul, VI) 
Assumption 2: U € N 
. (V=fact(U)) 
U- case analysis, Assumption 2 

(( U = 0) , l( V = fact( U))J) V « U > 0) , ( V = fact( U))) 
E spec-in-context 

Assumption 3: U = 

. (V=fact(U)) 

E equivalent-spec (U = => (V = fact( U) <=> V = 1)) 
(V = l) 

((U = 0)^(V = ID V « U > 0) , l( V = fact( U))j) 
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Focusing on the second occurrence of ( V = fact( {/)), we can again make a contex- 
tual assumption, this time from the specification (17 > 0): 

Assumption 4: U > 
. ( V = fact(U)} 

E equivalent-spec, factorial def., assumptions 

(3 171, VI • Ul = U - 1 A VI = fact(Ul) A V = VI* U) 
E lift-exists, lift-pand, pand-to-sand (x2) 

3 Ul, VI • { Ul = U - 1} , { VI = fact( Ul)) , ( V = VI * U) 
E assumpt-after-spec (x2) 
3 171, Vl» (U1=U- 1), 

l{ UK U} , { Ul e N} , ( VI = fact( 171)) j, 
(V = VI* 17) 

Next we use Assumption 1 to introduce a recursive call, making use of the assump- 
tion Ul = U — 1 to discharge the variant on the well-founded relation. 

• {UK U} , { Ul e N} , ( VI = fact( Ul)) 
E Assumption 1 
f(Ul, VI) 

Putting this all together and removing the assumptions, using remove-assumpt, we 
get 

{U GN},(V =fact(U)) 
E p , (([/ = 0),(V = 1))V 

((U > 0) , (3 Ul, V1*(U1=U- l),f(Ul, VI) , (V = VI * 17))) 

Closing the introduction of recursion, we have proved: 

(U, V) :-{U€N},(V=fact(U)) 
E p ref»(U, V):- 

«[/ = 0),(V = l))V 

((U > 0) , (3 Ul, VI • (Ul = U - 1) ,f(Ul, VI) , (V = VI * U))) 

er 

To translate this (informally) into Prolog, we: 

• turn the recursion block into a recursive procedure; 

• implement the arithmetic specifications using is; 

• express the disjunction using separate clauses; 

• make the existential quantification implicit. 

The result is: 
f(U,V) :- U=0, V=l. 

f(U,V) :- U>0, Ul is U-l, f(Ul,Vl), V is V1*U. 
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10 Example: N-queens 

In this section we present a non-trivial logic program refinement to demonstrate 
some refinement techniques that have been developed. The case study chosen is the 
N-queens problem. It is a generalisation of a chess problem, where eight queens are 
to be placed on a chess board so that no two queens may attack each other (they 
do not share a row, column, or diagonal). The generalisation is to have N queens 
on an N x N board. 

10.1 Specification of N-queens 

We first describe and motivate our specification of the N-queens problem. Given 
a natural number N , a solution to the N-queens problem can be represented by a 
list S of length N that contains numbers between 1 and N. The row number of 
the queen in column i is given by S(i), i.e., a queen at location (4,5) is indicated 
by 5(4) = 5. This representation implicitly guarantees that there is only a single 
queen in each column. 

We define a predicate psoln(S , N), which checks that in the list S there are 
no row clashes — no two row numbers are the same — and no diagonal clashes — the 
absolute value of the difference in the column numbers does not equal the absolute 
difference in the row numbers — as well as requiring the elements of S are valid row 
numbers in the range 1 to N. 

psoln{S, N) == list(S) A (Vi : l..#5 • S(i) G l.JV A 

(Vj : i + . S(i) S(j) A \i-j\ + \S(i) - S(j)\)) 

Our specification of N-queens constrains the length of a solution S to be N. 

nqueens = (N , S) :- {N G N}, (#5 = N A psoln(S, N)) 

10.2 Refinement of N-queens 

We note the following derived property of psoln. 

. i \ tt i Tii at\ ( psolntT, N) A H e 1..N A \ 
psoln(\H IT , N) v ,' ' ,. , TT mN (6) 

F \ notrow(H, T) A notdiag(H, T) J w 

where, for H a natural number and T a list of natural numbers, 

notrow(H, T) == (Vi : l..#T • H ^ T{i)) (7) 
notdiag(H, T) == (Vi : l..#T • i ^ \H - T{i)\) (8) 

We implement the N-queens solution using an accumulator-style program, by 
introducing a partial solution P as a parameter. P starts as an empty list, and 
is extended on each recursive call until a full solution of length N is built. The 
accumulator version of N-queens includes psoln(P, N) as an assumption, and must 
establish that the full solution S has a suffix of P and satisfies psoln(S, N). 

nqacc = (AT, P, S) :- {N G N}, {psoln(P, TV)}, 
(P suffix S A #5 = N A psoln(S, N)) 
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We implement nqueens by calling nqacc with the empty list, i.e., 

nqueens(N , S) □ nqacc(N , [ ], 5) 
The equivalence of these programs can be seen to hold by observing: 

psoln([],N) A [] suffix S 

Our task is now to refine nqacc. As with the refinement of the factorial program in 
Section 9.7, we use the recursion-intro law. We may assume the following inductive 
hypothesis during the refinement. 

{VN,P1,S» 

{PKP},{N eN},{psoln(Pl,N)}, 
{PI suffix S A #S = TV A psoln(S, TV)) 
^nq(N,Pl,S)) 

where PI -< P is the well-founded relation which holds when TV > #P1 > #P. 
(Note that PI is longer than P, but the well-foundedness is maintained by the 
upper bound of TV.) 

Now we begin the refinement of the body of nqacc. Wc apply the case-analysis law, 
to split the specification into the cases #P = TV and #P < TV, because psoln(P, TV) 
implies #P < TV. 

{TV e N},{psoln(P,N)}, 

((#P = TV), (P suffix S A #5 = TV A psoln(S, TV)) 
V 

(#P < TV), (P suffix S A #S = TV A psoZn(S\ TV))) 
The first disjunct is the base case: 

(#P = TV), (P suffix 5 A #S = TV A psoZn(S\ TV)) 
From the context we know psoln(P, TV). Hence the above is equivalent to 

<#P = TV) , (S = P) 
Next we focus on the branch that requires a recursive call. 

(#P < TV), (P suffix S A #S = TV A psoZn(S\ TV)) 

Since we are accumulating the solution, we prepend an element X to the front of 
P. We note that 

#P < #5 (P suffix 5 (3 X • [X | P] suffix 5)) 

Using the law spec-in-context we refine to 

(#P < TV) , ((3 X • [X | P] suffix 5) A #5 = TV A psoln(S, TV)) 

The predicate psoln(S, TV) has the property that any suffix P of S also satisfies 
psoln(P, TV). Hence the above is equivalent to the following. 

(#P<N), 

((31. P soln([I | P],TV) A [X | P]suffix5) A #S = TV A psoln(S, TV)) 
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We extend the scope of X to the end of the program, then use lift-exists to take it 
to the program level. We also convert the conjunction involving psoln{[X \ P], TV) 
to a sequential conjunction, with psoln on the left-hand side (using lift-pand and 
pand-to-sand). 

<#P<TV), 

(31. (psoln([X | P],N)) , ([X | P] suffix S A #S = TV A psoln(S,N))) 

We now establish the assumptions needed to match the inductive hypothesis. Since 
N > #[X \P]> #P we may introduce [X \ P] -< P. Since TV £ N is in context we 
may introduce it as an assumption. We also introduce {psoln([X \ P],N)} using 
law establish-assumpt. 

(#P<N), 

(3X • (psoln([X | P},N)), 

{[X | P] ~< P} , {N £ N} , {psoln([X | P], TV)}, 
([X | P] suffix S A #S = N A psoln(S, N))) 

We may now use the inductive hypothesis (9) to introduce a recursive call on 
nq(N,[X\P],S). 

<#P < TV) , (3 X . <p S0 Jn([X | F], TV)) , nq(N, [X \ P], S)) 

By observing the equivalence (6), and noting that the context includes psoln{P , TV), 
we may simplify (psoln([X \ P],N)) to (X £ 1..TV A notrow(X , P) A notdiag(X , P)) 
using spec-in-context. We also lift the conjunctions to the program level using lift- 
pand. Now closing the introduction of recursion, we get 

renq • (N,P,S):- 

{N £ N},{psoln(P,N)}, 
({#P = N),{P = S) 

V 

(#P<TV), 

(3 X • ((X £ 1..TV) A (notrow(X, P)) A (notdiag(X, P))), 
nq(N,[X | P],S))) 

er 

This is the overall structure of the program. However we must still implement 
(X £ 1..TV), (notrow(X , P)} and (notdiag(X , P)}. 

10.3 Subproblems 

The implementation of (X £ 1..TV) via a recursive procedure is straightforward and 
is omitted here. 

To refine the other two specifications we observe that they each require that a 
property V is established for every element in a list (cf. (7) and (8)). However uni- 
versal quantification is not executable. To remove the quantification we recursively 
establish the property V for each element in the list. This is encapsulated in the 
following law. 
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property-over-list 

(list(L)) A (Vi : • P(V,L(i))) C proc(F,i) 

where 

proc = rep • (V , L):- 

{L=[])V(3H,T.(L=[H | T}) , <P( V, H)) , p( 7, T)) er 

We use this law to derive an implementation of (notrow(X , P)). 

(list(P)) A (Vi : l..#P • X ^ P(i)) C norowclash{X , P) 
where 

norowclash = re norowc • (X, P):- 

(P = [ ]) V (3 #, T • (P = [ff | T]) ,{X^=H), norowc(X, T)) er 

In a similar way we derive an implementation of (notdiag(X , P)), though in this 
case we use a more general law property-over-list-indexed. 

p ro p e rty- o ve r- list-indexed 

(list(L)} A (V i : l..#L • V(i, V, L{i))) C proc{ V, L, 1) 
where 

proc = rep • (V, L, J):- 

(L=[])V(BH,T»(L=[H | T]> , <P( J, V, H)) ,p(V,T,J+ 1)) er 

The implementation of (notdiag(X , P)) follows. 

(Ust(P)) A (V i : l..#P • i ^ |X - P(i)\) C nodiagAcc(X , P , 1) 
where 

nodiagAcc = re nod • (X, P, J):- 

((P = []) V 

(3H,T • (P=[H \ T}) ,{J^\X- H\) , nod(W, T,J + 1))) er 

Whereas earlier laws are primitives corresponding to language constructs, the laws 
property-over-list and property-over-list-indexed are examples of higher-level refine- 
ment laws that encapsulate a design pattern for a particular data structure, in this 
case lists. 



10-4 Prolog implementation 

The refinement is completed by converting any parallel conjunctions to sequential 
conjunctions using the law pand-to-sand. From this program the following Prolog 
code can be generated by performing the translations noted in Section 9.7. 

nqueens(N,S) :- nqacc(N, [] ,S) . 

nqacc(N,P,S) :- length (P ,N) , S = P. 
nqacc(N,P,S) :- 

length (P,M) , M < N, 

memrng(X,N) , norowclash(X,P) , nodiagAcc(X,P, 1) , 
nqacc(N, [X|P] , S) . 

memrng(X,N) :- N > 0, X = N. 
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memrng(X,N) :- N > 0, Nml is N-l, memrng(X,Nml) . 
norowclash(_, [] ) . 

norowclash(X, [H I T] ) :- X =\= H, norowclash(X,T) . 

nodiagAcc(_, [] ,_) . 
nodiagAcc(X, [H|T],J):- 

XmH is X - H, abs(XmH,AbsXmH) , 

Jl is J+l, AbsXmH =\= J, 

nodiagAcc(X, T, Jl) . 

11 Tool support 

To support the refinement calculus, a prototype tool, Marvin (Hemer et at, 2001), 
has been developed based on the Isabelle theorem prover (Paulson, 1994). Marvin 
includes an embedding of the wide-spectrum language (and its associated semantics) 
in Isabelle/HOL. All of the refinement laws listed in Appendix A have been proven 
using the tool, and the factorial example presented in Section 9 has been performed. 

Isabelle is a generic interactive theorem prover, supporting a variety of different 
object logics, including first-order logic, higher-order logic and Zermelo Frankel set 
theory. Isabelle/HOL provides the datatype facility, used to declare recursive data 
structures. Isabelle/HOL also provides the primrec construct, allowing the user to 
define primitive recursive operators on recursive datatypes. 

11.1 Tool architecture 

Figure 3 shows the structure of the theories defined in Marvin. 

Marvin_lemmas extends the existing Isabelle/HOL theories with additional lem- 
mas required by the tool. The theories Term and Pred model terms and predicates 
respectively, using a datatype to declare their syntax. The theory Command mod- 
els Cmd, representing the commands in the wide-spectrum language; commands 
are defined using the datatype facility. State models program state as a set of 
bindings. Pointwise models a pointwisc union and pointwise intersection operator, 
corresponding to generalisations of U and R. The theory Ref Rels models the poly- 
morphic refinement relations "refines to" (C) and "refinement equivalence" (□). 
Execs models the type Exec and the function exec. Ref Cmd models refinement of 
commands, from which a number of useful refinement laws are derived. Re curse 
models the recursive features of the language. Ref Assume extends the notion of 
command refinement to include assumption context. 

The theories Command, Execs and Ref Cmd are described briefly below. 

11.2 Commands 

The theory Command introduces the type Cmd, corresponding to Cmd defined in 
Section 3. Commands are defined using Isabelle/HOL's datatype facility, and each 
command is described via a type constructor and the type of its arguments. 
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Fig. 3. Structure of the RefLP theory 



datatype Cmd 

I 



{ pred ) 
{ pred } 
Cmd A Cmd 
Cmd V Cmd 
Cmd , Cmd 
3 Var • Cmd 
V Var • Cmd 
fail 
abort 
skip 

PIdent (rterm) 



11.3 Executions 

The theory Execs introduces the execution type Exec and the function exec, map- 
ping a command to an execution. Firstly the type StateMap is defined, representing 
the set of partial mappings between initial and final states. 
StateMap == State -h> State 

Partial mappings are defined in Isabelle/HOL in terms of total functions. The labels 
Some and None are used to distinguish defined and undefined values. More precisely, 
for a partial mapping / and element x , if x is in the domain of / then there exists 
a y such that f (x) = Some y, otherwise f (x) = None. The label the can be used 
to strip away the label Some. 
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We define the type Exec, as a subtype of StateMap, using Isabelle's typedef 
facility. The set of executions corresponds to those partial functions satisfying the 
three properties of executions (1), (2) and (3) defined in Section 5.1: 

Exec == {e: StateMap | dom(e) = P {b. {b} G dom(e)} 
A V s G dom(e) . the e(s) C s 

A V s G dom(e). e(s) = Some {b. b G s & (e({b}) = Some {b})}} 

The function exec is defined using primitive recursion. The definition in Isabelle 
follows that given in Figure 2, except, for simplicity, definedness has been dropped 
from the definition of exec for specifications and assumptions. We also include the 
procedure call semantics (defined in Section 7.5). In the definition below, Pint and 
PUn correspond to pointwise intersection and pointwise union, and 'o ; ' corresponds 
to composition of partial functions. 

"exec p { x ) = (A s . Some (s n bnds(x)))" 

"exec p{x}=(As.ifsC bnds(x) then Some s else None)" 

"exec p (cl A c2) = ((exec p cl) R (exec p c2))" 

"exec p (cl V c2) = ((exec p cl) U (exec p c2))" 

"exec p (cl , c2) = ((exec p cl) § (exec p c2))" 

"exec p (3 v • c) = exists v (exec p c)" 

"exec p (V v • c) = forall v (exec p c)" 

"exec p fail = (A s. Some 0)" 

"exec p abort = (A s. if s = then Some else None)" 
"exec p skip = (A s. Some s) " 
"exec p fid(t) = 

(if fid: dom(p) 

then Rep_Exec((the (p fid))(t)) 

else (As. if s = then Some else None))" 

When processing a primrec declaration, Isabelle performs a number of checks. 
These checks include ensuring that there is exactly one reduction rule for each 
constructor, and that the variables on the right-hand side of each definition arc 
captured by any variables given on the left. In this way primrec declarations are 
a safe and conservative way of defining functions on recursively defined data struc- 
tures. 

Each of the reduction rules in the primrec declaration are added to the default 
simplification set, and are applied automatically when a simplification tactic is 
called. Thus, in general, the user does not need to refer to the reduction rules 
explicitly. 

1 1.4 Refinement rules 

The theory Ref Cmd introduces the refinement relations C and O for commands, 
defined in the context of an environment p. For example, the rule exists-mono is 
represented in Marvin as: 

env p Ih S C T ==> env plh3vSC3vT 

Refinement laws proven within Marvin include algebraic properties, predicate lift- 
ing laws, mononotonicity laws, specification and assumption laws, and laws which 
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extend and use the assumption context. In particular, the laws listed in Appendix 
A have all been proven within Marvin. The refinement laws have been used to refine 
a number of programs in Marvin. 

12 Conclusion 

We have presented a refinement calculus for logic programming. The calculus con- 
tains a wide-spectrum logic programming language, including both specification 
and executable constructs. We presented a declarative semantics for this wide- 
spectrum language based on executions, which are partial functions from states to 
states. Part of these semantics is a formal notion of refinement over programs in the 
wide-spectrum language. To illustrate the semantics we presented refinement laws 
proved in our semantics, and included the refinement of a non-trivial program. We 
also discussed a tool that supports the refinement calculus, based on the Isabelle 
theorem prover. 

In earlier work (Hayes et al., 1997), we defined the meaning of a command c in 
the wide-spectrum language by a pair of predicates: ok.c is a predicate defining the 
initial condition under which execution of the command is well-defined (essentially 
representing the assumptions the command makes about its context), while e/.c 
is the effect of the command, provided that its assumptions are satisfied. The two 
semantics are closely related in that, for every command c, 

ok.c = lJdom(exec c) 

ok.c A e/.c = (exec c)(ok.c) 

However, the earlier paper lacked a rigorous treatment of procedures, parameters, 
and recursion, and the semantics we use here is chosen to facilitate the presentation 
of those concepts. 

In (Colvin et al, 2000) we demonstrate how we represent types in the refinement 
calculus via specifications and assumptions, and include a wider discussion on con- 
textual refinement. In (Colvin et al., 1998) we introduce data refinement, where we 
change the representation of the types of a procedure. This allows a specification 
type to be replaced by an implementation type, or a procedure to be implemented 
by a more efficient representation. Data refinement is performed on a procedure-by- 
procedure basis. We have three kinds of data refinement, distinguished by interface 
issues. This work is extended in (Colvin et al, 2001), where we consider data re- 
finement on groups of procedures. We introduce a notion of module into the wide 
spectrum language, and by restricting the set of programs that may use a mod- 
ule, we can develop efficient representations of the original types. In (Colvin et al, 
2002) we present a prototype tool for generating Mercury (Somogyi et al., 1995) 
code from programs in our wide-spectrum language. We define what it means for 
a wide-spectrum program to be executable, and derive type and mode declarations 
by analysing the structure of the program. 

Acknowledgements. This work reported in this paper is supported by Aus- 
tralian Research Council grant number A49937007: Refinement Calculus for Logic 
Programming. 
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A Refinement laws 



A.l Algebraic laws 



pand-commute 

pand-assoc 

pand-idempotent 

por-commute 

por-assoc 

por-idempotent 

sand-assoc 

sand-idempotent 

pand-distrib-por 

por-distrib-pand 

left-sand-distrib-por 

left-sand-distrib-pand 

pand-distrib-sand 

right-sand-distrib-por 

forall-distrib 

exists-distrib 

pand-to-sand 



ci A c 2 □ c 2 A ci 

(ci A c 2 ) A c 3 □ q A (c 2 A c 3 ) 

c A c O c 

Ci V c 2 □ c 2 V ci 

(ci V c 2 ) V c 3 □ ci V (c 2 V c 3 ) 

c V c □ c 

(ci , c 2 ) , c 3 □ ci , (c 2 , c 3 ) 
(ci , ci) □ ci 

ci A (c 2 V c 3 ) □ (ci A c 2 ) V (ci A c 3 ) 

ci V (c 2 A c 3 ) □ (ci V c 2 ) A (ci V c 3 ) 

ci, (c 2 V c 3 ) □ (ci, c 2 ) V (ci, c 3 ) 

ci, (c 2 A c 3 ) □ (ci, c 2 ) A (ci, c 3 ) 

ci A (c 2 , c 3 ) C (ci A c 2 ) , c 3 

(ci V c 2 ) , c 3 □ (ci , c 3 ) V (c 2 , c 3 ) 

(VI • (ci A c 2 )) □ (VI • ci) A (VI • c 2 ) 

(3 X • (ci V cb)) □ (3 X • ci) V (3 A • c 2 ) 

ci A c 2 C ci , c 2 



A nfi c 2 



extend-scope-exists-over-pand 



(3 A • ci) A c 2 □ (3 A • ci A c 2 ) 



A. 2 Refinement relation laws 



refsto- reflex 
refeq-reflex 



c \— c 



c □ c 
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ci E c 2 ; c 2 E c 3 



refsto-trans 



refeq-trans 
refeq-symm 
refsto-anti-symm 
refeq-stronger-than-refsto 



c\ E c 3 
ci E3 c 2 ; c 2 □ c 3 

Cl □ c 3 

ci n c 2 
c 2 n ci 

ci E c 2 ; c 2 E ci 
Cl □ c 2 

ci □ c 2 



Cl E c 2 



pand-mono 



por-mono 



sand-mono 



exists-mono 



forall-mono 



A. 3 Monotonicity laws 

ci E c 2 ; c 3 E C4 

ci A c 3 E c 2 A c 4 
ci E c 2 ; c 3 E C4 



ci V c 3 E c 2 V C4 
ci E c 2 ; c 3 E c 4 

ci , c 3 E c 2 , c 4 
ci E c 2 

(31 • ci) E (31 • c 2 ) 

Cl E c 2 

(VI • ci) E (VI • c 2 ) 



lift-pand 
lift-por 
lift- exists 
lift-forall 



A. 4 Predicate lifting 

(P)A(Q) □ (PA Q) 
(P)V(Q) Q(PVQ) 
3I.(P)E(3I.P) 
VI • (P) □ (VI • P) 



weaken-assumpt 

remove-assumpt 

combine-assumpt 

establish-assumpt 



A. 5 Specification and assumption laws 

P^Q 



{P}^{Q} 

{A},c\ = c 

{A},{B}a{AAB} 
(P)0(P),{P} 
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equivalent-spec 



assumpt-after-spec 



introduce-assumpt 



introduce-spec 



assumpt-in-context 



spec-in-context 



equivalent-under-assumpt 



use-parallel-spec 



case-analysis 
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P=Q 
(P) □ (Q) 



(P)n( P ),{A} 

A. 6 Context 

r ^ a 

r^(cQ{4},c) 

r ^ b 

(cE (B) A c) 
rA^( Cl E e 2 ) 

r ^ ({A} , ci E {,4} , C2 ) 
rAAE)( Cl E c 2 ) 

r ^ «i4> , ci E (.4) , C2 ) 
4eee> (P^ Q) 



7 E» (P <g> Q) 

(/>A<P>Q(/)A(Q> 

r^pv o 

r^( C E((p), c )v((Q), c )) 



